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Tag-side attacks against NFC 


What is NFC? 


Contactless communication between two 
devices in close proximity 


Many uses, primarily door controls and 
payment systems 


ISO-14443 

Focuses on 13.56MHz NFC communication 

Defines the characteristics of the communication performed between tags and readers 
Two tag types based on it, A and B 


ISO-14443A is the most commonly used of the standards 


Low-level communication — 1۰701444۰3۸ 


Tags are powered by electromagnetic induction 

Communication is sent by the reader by disabling the field at specific intervals 

The reader uses the Modified Miller coding scheme for transmitting data to the tag 
Responses are sent by the tag by modifying the power being drawn from the reader 
Tags use the Manchester coding scheme to modulate the load 


Each communicated byte has an additional parity bit 


Modified Miller 


Disables field a defined intervals 
Minimises power loss 
Defined as follows: 


° و‎ bit after O bit: low for the first quarter of the transmission, followed by high for the remainder 
of the transmission 


° Obit after 1 bit: high for the entire transmission 


e 1bit: high for the first half of the transmission, followed by low for one quarter of the 
transmission, and high for the remainder of the transmission 


Manchester 


Performed by modifying the phase of the signal 
In NFC is communicated by modifying the load being drawn by the tag, using a subcarrier 


Basic Enumeration 


REQA(0x26) or WUPA(0x52) 


ATQA(0x?? 0x??) 


SEL(0x93 0x20) 


UID(Ox'?? Ox?? 0x7? 0x77 0x77?) 


SEL(0x93 0x70 0x?? 0x7? 0x7? 0x7? 0x7?) 


SAK(0x?? 0x7? 0x7?) 


Continued communication or enumeration 


In اچ‎ 


REQA(0x26) or WUPA(0x52) 


ATQA(0x?? 0x7?) 


SEL(0x93 0x20) 


UID(Ox?? 0x77 0x7? Ox 2? 0x77) 


UID(0x?? 0x7? 0x7? 0x7? 0x77?) 


SEL(0x93 0x21) 


Anticollision 


Performed when two tags are communicating with a 
reader 


Involves requesting responses based on partial 6 


Increases the number of bits requested until a single 
UID is identified 


Once communication is complete, the next tag can be 
identified and communicated with 


Encryption and Authentication - Mifare Ultralight 


An authentication key is sent to the tag 


If the key is accurate, the reader has authenticated with the tag and communication can 
perform 


Failed attempts are logged, and in some cases can lock the chip 
Can work with no authentication 


Support for a wider number of authentication methods in newer versions 


Encryption and Authentication — Mifare Classic 


Utilises Crypto-1 algorithm 
Reader requests authentication for a sector of the tag (0x60/0x61) 
Tag responds with a unique four byte nonce 


Reader responds with a random value, followed by an encrypted number generated 
from the original nonce 


Tag responds with an encrypted number generated from the nonce 
All further communication is encrypted as authentication has been performed 


Each sector of the tag can be authenticated using its own unique keys 


Encryption and Authentication — Mifare 6 


Based on different application IDs 

Authentication based on DES, 3-DES or AES depending on version and configuration 
Multiple keys can be used for authentication 

Authenticated similarly to Mifare Classic 


Not yet been broken in any meaningful manner 


Creating analysis tools 


Existing tools and projects 


Proxmark3 - https://proxmark.com/ 

Chameleon Mini - https://github.com/emsec/ChameleonMini 
HydraNFC - https://hydrabus.com/hydranfc-1-0-specifications/ 
SimpleNFC - http://www.nonan.net/nkruse/simplenfc 


Emutag - http://www.emutag.com/ 


NFC field detection 


LED and a coil of wire 


Useful for detecting when a field is active 


Creating a passive sniffer - RTL-SDR 


Powerful SDR, able to tune between 25MHz and 7 
Configurable sample rate 
Libraries available for simple communication 


Problems: 


Cannot tune down to 13.56MHz without hardware modifications 
Cannot run at a low sample rate 
Bundled with weak antenna 


Not built for purpose DVB-T+DAB+FM RE 


Creating a passive sniffer - RTL-SDR 


Possible to tune to harmonic frequency, providing adequate signal (27.12MHz) 
Can synchronise with the reader by setting sample rate to 1.695MHz 


Antenna modifications not required, introducing a coil to the NFC field provides 
adequate power for analysis 


Possible to detect communication from the reader to the tag 
Constant signal means automatic gain control is possible 


Accurate responses, providing real-time analysis of communication 
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Building a tag 
Mifare Classic was used as the initial tag type 


Wanted to build it with no standard NFC chipsets, as these would limit access to raw 
communication 


Wanted to build it with minimal components 


Full implementation of Crypto-1 authentication would be required, adding complexity to 
the project 


By fully implementing the protocol weaknesses could be identified in it 


Hardware requirements 


Inductive coupling would be required in order to receive signal from reader 
This signal would need to demodulated by amplitude 


An appropriate Microcontroller which could synchronise to 13.56MHz would be 
required 


The Microcontroller would need to be fast enough for encryption calculations 


Sufficient memory would be required for storage of data 


Inductive coupling - LC circuit 


A circuit used to resonate with the field 

Made of an inductor and a capacitor 

For this purpose, a large coil of wire acts as inductor/antenna 

Coil of wire was tuned to 10pF capacitor 

Resonance can be checked with logic analyser, assessing whether wave frequency is 
13.56MHz 


#0.2us 0۵.305 #0.4us +0.5 #0.6us 310.75 0.805 0.905 | +0.1us 0۵0.205 


Demodulation - envelope detector 


Used in circuits to demodulate signal based on amplitude 

Made from a diode, resistor and capacitor 

Works by rectifying the signal, and then smoothing it 

Values can be guessed by trial and error 

Testing concluded that a 1K resistor and a 220pF capacitor were appropriate for this circuit 
Appropriate values show Modified Miller communication in logic analyser 


400us 
+HoDus +20us +80۳5 Alus | 1005ح‎ +240us ¿+30us ¿+40us Halus +60us ہی‎ ں0٥‎ 


الا الا لا لا ا الا ۲ 


Receiving circuit 


Final circuit built with very simple layout 
Accurately receives communication from a reader with sufficient voltage to trigger GPIO 


No need for additional smoothing or regulation 


Microcontroller selection 


ATTiny84 was selected for the initial device 

Utilises 8KB of program space, and 512B of RAM 

Can be programmed using a standard Arduino, or dedicated programmer 
Able to use external crystals to run at a specific frequency 

DIP package makes it easy to build into prototypes 

Receiving circuit could be attached to GPIO pins 

Good support for interrupts and timers 

Bad support for debugging 

8-bit architecture may cause problems with fast calculation 


Implementation 


A 13.56MHz crystal and matching capacitors were connected to the ATTiny 
Receiving circuit was connect to an input pin and output pin 


Due to UART not being feasible with non-standard clock, debug strings were communicated 
via software-based SPI 


An LED was attached to confirm when the device was active 


The responses and state machine used by Mifare Classic were implemented, allowing the 
device to behave as a tag 


Timing issues 


Using a 13.56MHz crystal, ATTiny was synchronised with reader 

At predefined intervals at 847.5KHz, value of GPIO was read 

Attempting to match signal against exact timings provided inconsistent results, commands 
were only read accurately 50% of the time 

This was found to be due to clock drift on the MCU 

Instead, interrupts were configure to run whenever the signal went low, and times between 
interrupts were assessed 

This yielded a 99% accuracy 


400us 
» +90us | #10us +20us +30us ¡+40us +50us +60us | 


Implementing Crypto-1 

Crapto-1 library and Crypto-1 papers used as a reference for implementation 

Found to be based on 48-bit keys utilised as two 24-bit keys 

8-bit architecture of MCU meant that all multi-byte calculations would take much longer 


Additionally, AVR machine code only allows for one bit-shift at a time, making it 
unsuitable for cryptography 


Slow responses to authentication requests would cause compatibility issues 


The filter function used for all calculations was identified to be the slowest function in 
use 
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Implementing Crypto-1 


All Crypto-1 code was converted from C to AVR assembly 
SimAVR was used to compare optimised assembly version against C version in 
environment with more effective debugging 
All calculations which would be treated as 32-bit were performed as 24-bit operations 
All bit-shifts were converted into more efficient operations: 

e 16-bit shifts - move the two upper bytes to the lower two bytes 

e §8-bit shifts - move the second lowest byte to the lowest byte 

° 4-bit shifts - use the AVR SWAP operation to swap the upper and lower nibbles 

e 92-bit shifts — two traditional shift operations 

e 1-bit shifts — one traditional shift operation 
These optimisations increased the speed of the calculations by ~10 times 


bread endShiftSixteenBit 
mov r16, ۳26 ; this will shift 16 bits in two operations rather than the ton it usually takes 
mov ۳17, r27 
endShiftSixteenBit: 
1di ZH, hi8(secondLookupTable) ; set up first space for lookup 
ldi ZL, lo8(secondLookupTable) 
add ZL, r21 
| ade ZH, 1 


breq endShiftEightBit 
mov r17, 6 
endShiftEightBit: 
1di ZH, hi8(firstLookupTable) ; set up first space for lookup 
Idi ZL, lo8(firstLookupTable) 
add ZL, 
adc ZH, 


breq endShiftFourBit 
swap 7 
andi r17, 00۴ ; may not be necessary 
endShiftFourBit: 
101 ZH, hi8(firstLookupTable) 
101 ZL, lo8(firstLookupTable) 
add ZL, r20 
ade ZH, 1 
Ipm r20, Z 
cpi r20, 0; if its zero, skip 
breq endShiftTwoBit 
Isr 7 
کا‎ FET 
endShiftTwoBit: 
ldi ZH, hi8(secondLookupTable) 
ldi ZL, lo8(secondLookupTable) 
add ZL, r24 
ade ZH, 1 
lpm r24, Z 
cpi r24, 0 
breq endShiftOneBit 
Isr ri7 
endShiftOneBit: 
andi r17, 1 
mov r24, 7 
pop 6 
pop 7 
pop 8 
ret ; make sure r24 contains 8 bit response value - actually a 1 bit response 
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Hardware limitations 


Microcontroller is too slow to perform complex operations in time, 13.56MHz clock 
speed is not enough to perform additional functions 


~400 bytes of RAM and ~7000 bytes of Flash were used for the implementation, 
leaving little room for further functionality 


512 bytes of EEPROM memory were not enough to store an entire tag 
Debugging complex functionality on AVR Microcontrollers is a difficult process 


Limited number of pins means limited number of additional peripherals could be 
added 


Some readers were still not compatible, as they require fast response times 


Building a better device 


A more powerful Microcontroller was selected — STM32L496ZG 


1MB of Flash available, 320KB of RAM (640x more than the 
ATTiny) 
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Much faster clock speed, capable of performing at 72MHz 


32-bit architecture could improve encryption calculations 
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Large number of useful peripherals, including USB and UART 
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Easy to program and debug using development software 


Can be built using the same circuitry and logic as previous device 


Building a better device 


Pin configurations and clock speeds can be set in STM32Cube 

Very little modification to core codebase was required — only timers and 
interrupts needed to be modified 

Synchronisation issues could occur due to lack of standard clock rate 


Building a better device — Synchronisation 


Internal clock of the chip was not able to tune to 13.56MHz 


This would not be a problem for receiving data, but would be a problem for transmitting 
responses 


Use of an external crystal was not ideal, as it would increase complexity of the board 
Without an accurate clock, the device would fall out of sync with the reader 


The STM32 can run at a large number of frequencies, it could be possible to find a clock 
at a close enough frequency, without being perfectly in sync 


Each possible frequency was assessed in order to find the most suitable candidate 
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Additional features - Multi-tag support 


Can be implemented by having several instances of the same state machine 

Handling of multiple requests can be performed by forcing anticollision, or more easily 
by cascading requests so that only one selection is performed at a time for each 
emulated tag 


This can be used to exploit weaknesses related to selecting multiple tags 


Not hugely useful, as readers rarely implement this functionality 


Additional features - Dynamic Crypto-1 Key Generation 


Some readers generate unique keys depending on the UID of the tag 


If the algorithm for these can be reverse engineered, keys can be calculated as 
authentication is requested 


This can allow for dynamic modification of UID values without adversely affecting 
authentication 


12:31 PM ... $ © all A 
ZÑ Taginfo < = 


INFO NDEF EXTRA TECH 


= Technologies supported 


ISO/IEC 14443-4 (Type A) compatible 
ISO/IEC 14443-3 (Type A) compatible 
ISO/IEC 14443-2 (Type A) compatible 


= Android technology information 


Tag description: 

> TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA] 
android.nfc.tech.IsoDep 

> Maximum transceive length: 65279 bytes 

> Default maximum transceive time-out: 618ms 

> Extended length APDUs supported 

android.nfc.tech.NfcA 

> Maximum transceive length: 253 bytes 

> Default maximum transceive time-out: 618 ms 


= Detailed protocol information 


ID: 16:18:FF:ED 
ATQA: 0x4403 
SAK: 0x20 
ATS: OxAE 


NIE 


Additional features - Implementing DESFire 


Can present as DESFire by modifying SAK and ATOA 
response values 


Implemented by replaying legitimate requests from readers 


Protocols are robust, when a valid response can’t be provided, 
the reader will try again 


Authentication functionality is well documented 


The Mifare DESFire Tool Android Application can be used to 
develop and test this functionality 


Security Weaknesses 


Crypto-1 Weaknesses 


Weaknesses in this algorithm have been known for a long time, most importantly in the 
paper “Dismantling Mifare Classic”, which outlines the most key weaknesses. 


Crypto-1 utilises 48-bit keys, split into 24-bit keys, this can be brute forced 
Authentication is vulnerable to replay attacks 


Nonces used to authenticate can be used to recover 32-bits of keystream from 
authentication 


Rollbacks from the authentication can be performed to fully recover the initial key 


Attacking Crypto-1 from the tag 


Key recovery for a sector can be achieved from two authentication requests when 
emulating a tag: 
Authentication is allowed to progress until the reader sends a response to the tag’s 
initial nonce 
This response contains a random value followed by an encrypted value generated by 
the tag’s nonce, the generated value can be calculated and XORed with this, 
providing 32-bits of keystream 
The two 24-bit keys generated from the 48-bit initial key are used to calculate each 
alternating bit of the keystream, reducing these values from ~16 million possible 
24-bit keys to ~200,000 
Matching key pairs can be checked in order to find combinations which generate 
the 32-bit keystream 
These keys can be rolled back through the random value and the initial nonce in 
order to recover the initial key 


Attacking Crypto-1 from the tag 


RD: 60 08 bd T7 
TG: O1 02 03 04 
RD: 8F 18 70 37 8f 16 ab 9 


Attacking Crypto-1 from the tag 


This approach can be used to perform offline cracking on Mifare Classic keys 
Keys can be recovered in under ten minutes 


This is more efficient than reader-based attacks on tags, but is impractical in a real- 
world setting 


This functionality is available on the Proxmark and Chameleon Mini, and is part of the 
core functionality of Crapto-1, but is not widely used to due to practicality in most 
contexts 


Attacking Crypto-1 from the tag - Demonstration 


A Mifare Classic reader with no known research was selected — the NFC reader used by a 
Japanese Video Game 


Reader was identified to use USB for communication, which was reverse-engineered using 
the USBProxy tool and a Beaglebone Black, the protocol was found to be simplistic and 
allowed for access to tag UIDs and block data 


The reader was found to not be compatible with the Proxmark or Chameleon Mini due to 
the speed with which it required responses from tags 


A tool was written which identified tags on the reader and tried to read data from it 


Attacking Crypto-1 from the tag - Demonstration 


UIDs, sector numbers and authentication values were generated from the STM32 device 
A custom tool was written which processed these in order to recover keys 

Keys were verified against the reader after being generated, showing that they could be 
recovered 

A large number of different keys were generated by emulating a large number of unique 
UIDs, this allowed for identification of differences between keys, and could help with 
reverse engineering key generation algorithms 


Figure placement 02 a7 20 14 ar 01 02 03 04 6c 30 cf Oc 1c 96 be bb 
UID Update, reading block: 00 - c6 je f4 7 02 a7 20 14 a7 01 02 03 04 a3 a8 ba 52 79 f9 Ge 2d 
Data: c6 76 f4 a7 20 14 a7 02 a7 20 14 a? 01 02 03 04 d3 68 be 98 ae ba 26 09 
Figure placement 02 ar 20 14 a7 01 02 03 04 la 97 72 34 OF 73 95 4 
Figure placement 02 a7 20 14 a7 01 02 03 04 dd 57 d5 4e 11 Of 48 4d 
UID Update, reading block: 01 - c6 Ye f4 a7 02 ar 20 14 a7 01 02 03 04 af b3 8b b4 c7 d5 Ef 82 
Data: c6 76 f4 a7 20 14 7 02 ar 20 14 a7 01 02 03 04 3f 6c dc 3d 32 33 68 86 
Figure placement 02 a7 20 14 a7 031 02 03 04 73 ba c8 6d 80 7f ad e9 
Data: 6ع‎ je f4 a7 28 14 7 02 a7 20 14 a7 01 02 03 04 Ya 46 a9 TE 28 cS OF e4 
Data: c6 7e f4 a7 20 14 7 02 arf 20 14 arf 01 02 03 04 44 a0 a6 de 97 31 Oa Ta 


Data: ch 7e f4 a7 76 14 7 


Sector: 02 Uid: a7 30 10 a nonce: 01 02 03 04 resp: ed d9 5d 51 ff bb 67 62 
Successor: 04030201->56edf820->adcd2b3c 
Sector: 02 Uid: a? 30 10 a? nonce: 01 02 03 04 resp: ed 2e da f1 23 55 63 13 
Successor: 04030201->56edP820->adcd2b3c 
Sector: 02 ld: a7 30 10 a7 nonce: 01 02 03 04 resp: 83 8ء‎ 9e cc f5 95 29 ae 
Successor: 04030201->56edf820->aded2b3c 


otal potentials 0 - 23538(0) 31492 - 0 
ot working matched on subsequent at: cSafe6 8ت‎ ٤8 
est key: 29 6f af 36 99 OF 


9m58. 366s 
901058. 35 
0010. 083s 


Crypto-1 - Improvements 


An increased key size would significantly increase the complexity of the attack 
Usage of a single, large key would prevent brute forcing of key stream values 
An improved PRNG on the tag would limit replay attacks 


Removing known plaintext from authentication would remove opportunity for exploitation 


Raw protocol weaknesses 


Most NFC chipsets don’t support control of the initial enumeration procedures, leaving 
it only accessible for testing by dedicated devices 


Initial enumeration is performed by all tag types, meaning that weaknesses can be tested 
on a large number of readers 


No limits on response sizes leave readers potentially open to memory corruption 
weaknesses 


The greatest weaknesses lie in the anticollision procedures 


۱۸ Texas 
INSTRUMENTS 


www.ti.com Pseudo-Code for 150144434 Tag Detection 
Combine the known bytes and the received bytes to form the complete UID. 
1. Reset bit B7 (B7 = 0) of the ISO control register to enable reception with CRC. 
2. Send a SELECT command with the appropriate cascade level, NVB = 0:70 and complete UID. 
3. Wait for End of TX interrupt. 
4 


. Wait for End of RX interrupt. 
Read the data (received from the tag) in the FIFO. Examine the SAK field in the tag response. If the 


cascade bit is set, UID is not complete. Therefore, increase the cascade level and initiate a new anti 
collision sequence. 


Note: Due to the recursive nature of the anti-collision algorithm, there is a risk of stack overflow. It 
is highly recommended that the user implement stack overflow check in the firmware. 


The anti collision loop of the 15014443A protocol is described in more detail in the flowchart below. 


Exploiting anticollision 


By constantly responding to requests with corrupted communications, the reader will 
ask for an increasing number of bits of the UID, eventually overflowing and requesting a 
size too large for the buffer 

This can often cause crashes 

This feature is rarely implemented, most readers only support one card at a time 

This weakness is known, but is still found in some readers 


00000096 3532 RD: 93 07 TT TT TF TT fr fr TT TT fr ff ff FF 00 
00000097 3536 RD: 93 00 TT TT fr TT fr TT TT fr fr fr TT TT 00 
00000098 3530 RD: 93 01 TT TT TT TT TT TT TT TT TT TT TT TT ol 
00000099 3437 RD: 93 03 TT TT TT TT FF TF TT TT TT TT TT ff 03 
00000098 3312 RD: 93 03 TT TT TF TT TF TF TT TT TT TT TT TT OF 
000000399 3434 RD: 93 07 TT TT TF TT TT TT TT TF TT TT TT TT OF 
0000009 3434 RD: 93 05 TT TT TF TT TT TT TT TT fF FF TT fF 1F 
00000090 3366 RD: 93 06 TT TT TT TT fr fr TT TT TT TT TT TT 3f 00 
00000096 3379 RD: 93 07 TT TF TT TT TF TT TT TT fr TT TT ff 7٢ 00 
0000009: 3618 RD: 93 00 TT TT TF TT TT TT TE TE TE TT TE TE TE 00 
00000080 3889 RD: 93 01 TT TT TT TT FF TT TT TT TT TT TT TT TT 1 
00000081 4215 RD: 93 03 TT TT TF TT TT TT TF TT TT fr TT TT ff 03 


High level protocol weaknesses 


Each tag type has its own weaknesses 


Entire stack lends itself to fuzzing beyond enumeration, as this data can be manipulated 
by most NFC chipsets 


NDEF data has the greatest potential for weaknesses, as it has a large number of data 
types and features 


Authentication mechanisms often have known plaintext weaknesses 


Capabilities of tag hardware mean that complex authentication and encryption is not 
possible 


Compiling research 


Future work 


Source will be released - RTL-SDR, AVR and STM32 tools 
Boards will be designed 
DESFire will be fully implemented, and each element of it will be assessed 


More tag types will be researched for weaknesses 


OOR ae 
Questions PEN [EST PARTNERS 


Christopher Wade 
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